The present system relates to the field of network troubleshooting and analysis and particularly to a system and method of identifying tiers present in an activity data file.
In the field of network application performance prediction and analysis, it is not uncommon to capture network activity, such as packets transferring between points in a network, using packet sniffers, protocol analyzers, etc. In operation, data related to network activity, such as packet transfers, may be recorded to one or more activity data files, such as trace files. The activity data files may be later analyzed using one or more analysis tools.
Typically, one part of the analysis process is to determine the network devices, termed tiers or nodes, which are responsible for activity that is recorded in the activity data file. It is also desirable to determine the number of network devices responsible for activity. This is typically accomplished by assigning one tier to each unique IP address. However, in many cases this approach is insufficient. For example, in a case wherein some of the network activity is attributed to a router (tier) that utilizes network address translation (NAT) to route data from an internal network to an external network, such as the Internet, activity that actually is attributed to multiple objects (e.g., devices or portions thereof, such as a network interface card (NIC)) within the private network may all appear within the activity data file as attributed to the router. This problem occurs because in the use of NAT, separate (private) addresses of the multiple network objects may be mapped to a single public Internet Protocol (IP) address. Due to the NAT, the public IP address is actually a virtual IP address that is resolved to the private IP address of a given object by the router when data is received from the public network. Similarly, when data is received by the router from a device within the internal network (e.g., private network), the source of the data is altered by the router to reflect the virtual IP address of the router before being sent to a destination device accessible on the public network. It is desirable to be able to separate out the network activity (e.g., traffic) sent from/to a given host to/from the virtual address.
This problem may be ameliorated by locating a packet sniffer within the private network so that the tiers responsible for activity may be captured by the sniffer, however, this approach is not practical for many applications. For example, it may not be practical to position a sniffer within each of potentially numerous private networks that may exist in a network configuration and/or one or more of the private networks may not be under the direct control of the party operating the activity capture. In addition, different private networks may internally utilize a same addressing scheme (e.g., 192.168.0.1's). So even in a case wherein a sniffer is placed within the private network, if you simply combine the trace files, you might end up seeing several (different) tiers having a same address. Further, it is oftentimes more convenient to capture network activity from some point outside of the network portion wherein NAT occurs. In these and other instances where more than one machine appears to have the same IP address (e.g., load balancing, failover, transparent proxying, overlapping networks, etc.), the analysis tools may determine that there are fewer tiers than there really are, and thereby, present the user with inaccurate or incomplete data.
It is an object of the present system to overcome disadvantages and/or make improvements in the prior art.
The present system includes a system, method and device for remapping a Media Access Control (MAC) address mapped to a virtual IP addresses. The method includes examining an activity data file to identify the virtual IP address mapped to the MAC address and remapping the identified MAC address to an IP address. The MAC address may be one of two or more MAC addresses mapped to the virtual IP address. The virtual IP address may be identified by determining that the virtual IP address has at least two mapped MAC addresses. Other criteria may also (or in place of) be utilized for identifying virtual IP addresses. A portion of the IP address may be automatically generated. A user may be queried to confirm the generated portion of the IP address. The portion of the IP address may be determined based on prior user entrance of an IP address that includes the portion of the IP address. The portion of the IP address may be predetermined by a user assigning a naming convention.
The remapping may include querying a user to enter a portion of the IP address. Tiers may be assigned to each MAC address recorded in the activity data file. A user may be provided with a interface (UI) depicting the virtual IP address and the MAC address(es) including an identification whether the virtual IP address and the corresponding MAC address(es) are sources or destinations for given activity. The UI may include a tree-view depicting the virtual IP address and the MAC address(es). The UI may include a table view depicting the MAC address(es). The table view may include an indication of the virtual IP address and a field for the IP address. The table view may list a remapped MAC address. The remapping may be saved in the activity data file or in another activity data file. A number of tiers corresponding to activity recorded in the activity data file may be determined after the MAC address is remapped. Through operation of the present system, a source and destination endpoint (e.g., true endpoints) may be readily determined.